What Is SSL/TLS? HTTPS Certificates and Security 2026

SSL and TLS Explained: How HTTPS Actually Secures Your Data in 2026

Security guide by techuhat.site

Every time you see https:// in a browser address bar, a security protocol is actively protecting the connection between your device and the server you are communicating with. That protocol — technically TLS (Transport Layer Security), though still commonly called SSL — is one of the most widely deployed security standards on the internet. As of 2025, approximately 95% of web traffic across Google's systems is encrypted via HTTPS, according to Google's Transparency Report.

Despite how common HTTPS is, the technical mechanisms behind it are frequently misunderstood. SSL and TLS are not the same thing. A padlock icon does not mean a site is safe or trustworthy — only that the connection is encrypted. And the way certificates bind to domain names involves a chain of trust that has important security implications. This article explains how TLS actually works, what certificates are, what the real guarantees of HTTPS are and what they are not, and what the current state of the protocol looks like in 2026.

SSL vs TLS: The Terminology Explained

SSL — Secure Sockets Layer — was the original protocol, developed by Netscape in the mid-1990s. SSL 2.0 was released in 1995, SSL 3.0 in 1996. Both are now cryptographically broken and deprecated. TLS — Transport Layer Security — is the successor. TLS 1.0 arrived in 1999, followed by TLS 1.1 (2006), TLS 1.2 (2008), and TLS 1.3 (2018). TLS 1.0 and 1.1 were disabled by all major browsers in 2020. TLS 1.2 and TLS 1.3 are the current active standards in 2026.

The reason "SSL" persists in everyday usage despite being technically replaced is historical inertia — the term "SSL certificate" is still used universally even though modern certificates work with TLS. When someone says SSL today, they almost always mean TLS. Understanding this distinction matters because references to SSL vulnerabilities point to genuinely deprecated, broken protocol versions that should not be running on any production server.

What TLS 1.3 improved over TLS 1.2: TLS 1.3 removed all weak and legacy cipher suites, reduced the handshake from two round trips to one (faster connection setup), eliminated RSA key exchange which lacked forward secrecy, and made 0-RTT session resumption available for returning connections. These are significant security and performance improvements. Servers still running only TLS 1.2 are behind current best practice, and servers supporting TLS 1.0 or 1.1 have a real security problem.

How the TLS Handshake Works

Before any data is exchanged over an HTTPS connection, the client and server perform a handshake — a sequence of messages that establishes the session encryption keys. In TLS 1.3, this takes one round trip.

• Client Hello — The client sends its supported cipher suites, a random value, and key share data for the key exchange algorithms it supports (typically X25519 elliptic curve Diffie-Hellman).
• Server Hello — The server selects the cipher suite, sends its own key share data, and its certificate. Both sides independently compute the same session key using the exchanged key share values — without transmitting the key itself. This is the Diffie-Hellman key exchange.
• Certificate verification — The client verifies the server's certificate against its trust store. If the chain is valid and the root CA is trusted, the server is authenticated.
• Finished — Both sides confirm the handshake and encrypted data begins flowing.

The critical property here is forward secrecy. TLS 1.3 uses ephemeral Diffie-Hellman key exchange, meaning the session key is generated fresh per connection and never stored. Even if an attacker records all encrypted traffic and later steals the server's private key, they cannot decrypt past sessions — the session keys no longer exist. This is why TLS 1.3's elimination of RSA key exchange (which did not provide forward secrecy) was a major security improvement.

What TLS Certificates Are and How the Chain of Trust Works

A TLS certificate is an X.509 digital certificate serving two purposes: it contains the server's public key used during the handshake, and it provides cryptographic proof that this public key belongs to the entity controlling the domain name listed in the certificate.

Certificate Chain Structure

Certificates are not verified against a single master list. They form a chain of trust. A server certificate is signed by an intermediate Certificate Authority (CA). The intermediate CA's certificate is signed by a root CA. Root CA certificates are pre-installed in operating systems and browsers — they are the ultimate trust anchors. When your browser verifies a certificate, it walks up the chain: server cert → intermediate CA → root CA. If the chain is valid and the root is trusted, the server is authenticated.

Root CA private keys are kept offline in physically secured facilities and used as rarely as possible. Intermediate CAs handle day-to-day certificate issuance. If an intermediate CA is compromised, it can be revoked without touching the root.

Validation Levels: DV, OV, and EV

Certificates come in three validation levels based on how thoroughly the CA verified the applicant:

• Domain Validation (DV) — CA verifies only that the applicant controls the domain, by placing a file on the server, adding a DNS TXT record, or responding to an email. No organization identity check. Let's Encrypt issues DV certificates. Free, automated, and sufficient for encryption — but says nothing about who operates the site.
• Organization Validation (OV) — CA verifies domain control plus confirms the organization is a registered legal entity. Organization name appears in certificate details.
• Extended Validation (EV) — Most rigorous check including legal identity, physical address, and authorization. Historically showed green address bar in browsers — removed by Chrome and Firefox in 2019 after research showed users did not meaningfully distinguish it.

A padlock does not mean a site is safe: The padlock means your connection is encrypted in transit. It says nothing about the legitimacy of the site itself. Phishing sites routinely use HTTPS — getting a free DV certificate from Let's Encrypt takes minutes. When you see a padlock, your traffic cannot be intercepted between your device and the server. Whether that server belongs to a legitimate organization is a separate question that the padlock does not answer.

How Certificates Bind to Domain Names

A certificate is issued for specific domain names listed in its Subject Alternative Name (SAN) field. The browser checks that the domain in the certificate matches the URL's domain. A mismatch produces a certificate error and blocks the connection.

Wildcard certificates cover a domain and all its immediate subdomains — *.example.com covers app.example.com, mail.example.com, and any other single-level subdomain, but not api.mail.example.com. Wildcard certificates simplify management for organizations with many subdomains but carry higher risk — one compromised private key exposes all subdomains simultaneously.

Certificate Transparency (CT) is a public logging system requiring all trusted certificates to be recorded in publicly auditable append-only logs before browsers will accept them. Chrome has required CT since 2018. The practical implication: every certificate ever issued for your domain is publicly searchable at tools like crt.sh. Organizations should monitor CT logs for certificates issued for their domains without their authorization — an early indicator of domain hijacking or rogue issuance. CAA (Certificate Authority Authorization) DNS records let you specify which CAs are permitted to issue certificates for your domain, preventing unauthorized issuance at the CA level.

Let's Encrypt and the Automation of Certificate Management

Before Let's Encrypt launched in 2016, obtaining even a basic DV certificate typically cost money and required manual renewal annually. Let's Encrypt changed this by providing free, automated certificate issuance through the ACME protocol — Automated Certificate Management Environment, standardized as RFC 8555.

ACME allows a server to automatically prove domain control and obtain a certificate without human involvement. The HTTP-01 challenge places a specific token at a specific URL path; the CA fetches it, confirms the expected value, and issues the certificate. DNS-01 creates a TXT record in DNS instead — required for wildcard certificates.

As of 2025, Let's Encrypt has issued over 4 billion certificates and has over 400 million active certificates. It fundamentally changed HTTPS economics — making encryption free and automated rather than an annual paid process. Let's Encrypt certificates expire after 90 days, intentionally shorter than commercial certificates to limit damage from key compromise. The expectation is automated renewal via ACME clients like Certbot, acme.sh, or web servers with built-in ACME support like Caddy.

If you are manually renewing certificates, automate it now. 90-day expiry with manual renewal is a reliability problem waiting to happen. ACME clients can handle renewal automatically with cron jobs or systemd timers. Let your infrastructure manage certificates — you have better things to do than track certificate expiry dates.

Notable TLS Vulnerabilities and What They Taught Us

TLS 1.3 addressed most historical protocol-level vulnerabilities, but understanding the major incidents helps explain why current configurations are the way they are.

POODLE (2014) — Exploited a downgrade attack to force connections to SSL 3.0, which had a padding oracle vulnerability. The fix was disabling SSL 3.0 across the internet. TLS_FALLBACK_SCSV was introduced to signal that a client is capable of better than the version it is offering, preventing servers from accepting unnecessary downgrades.

Heartbleed (2014) — A buffer over-read vulnerability in OpenSSL's heartbeat extension allowed attackers to read up to 64KB of server memory per request. In practice, this could expose private keys, session tokens, and other sensitive data. The incident drove mass certificate replacement and accelerated adoption of forward-secret cipher suites.

DigiNotar (2011) — A Dutch CA was compromised and used to issue fraudulent certificates for google.com and hundreds of other domains. These certificates could enable man-in-the-middle attacks against users — particularly Iranian users where the attack was believed to be targeted. DigiNotar was removed from browser trust stores and went bankrupt within months. The incident directly motivated the development of Certificate Transparency and CAA DNS records.

TLS Configuration Checklist for 2026

Running HTTPS is the baseline. Running it correctly requires attention to configuration. The standard tools for auditing and configuring servers:

• Mozilla SSL Configuration Generator (ssl-config.mozilla.org) — Server-specific configuration files for Nginx, Apache, HAProxy, and others, updated regularly to reflect current best practice. Start here for any new server setup.
• SSL Labs Server Test (ssllabs.com/ssltest) — Grades your server's TLS configuration from A+ to F, identifies specific issues like weak cipher suites, missing HSTS, or incomplete certificate chains. The standard audit tool.

Current recommended configuration: support TLS 1.2 and TLS 1.3 only — disable SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1; use only cipher suites providing forward secrecy; enable HSTS (HTTP Strict Transport Security) with a long max-age to prevent protocol downgrade attacks; add CAA DNS records specifying which CAs may issue for your domain; automate certificate renewal via ACME; and consider submitting your domain to the HSTS preload list to eliminate the trust-on-first-use window.

HSTS deserves specific mention. When a server sends an HSTS header, the browser remembers that domain requires HTTPS and refuses HTTP connections for the duration specified — even if a user types the URL without HTTPS. Submitting to the preload list embeds this requirement directly in browser builds, eliminating the first-visit vulnerability entirely.

More security guides at techuhat.site

Topics: SSL TLS explained | HTTPS how it works | TLS 1.3 vs 1.2 | Certificate transparency | Let's Encrypt | Web security 2026 | HSTS explained